We’re hoping that our recent series of blog posts on clean code left you hungry.

• Hungry for code that’s easy to understand.
• Hungry for code that can be modified to meet future business needs.
• Code that costs less, and gives you confidence that it’s doing what you think it’s doing.

We’re well aware that the code that we work with on a daily basis often leaves us feeling like we’re staring at a TV dinner and wishing it were a nice steak.

Satisfying your hunger

But the question is: How should you satisfy that hunger? How do you get your code from where it is to where you want it to be? And, of course, the answer is “refactoring.”

Refactoring – improving the structure of your code, while keeping the functionality the same.

Refactoring is a topic about which many classic books have been written. Books about techniques of refactoring. Books about Design Patterns that you can emulate. Books about how to get untested legacy code under test.

So where should you start?

The temptation is to dive right in. Halt all new features in your code, and get it cleaned up. After all, once it’s well-organized, it will be *easy* to add new features. You want that steak, and you want it now! But this is simply not a sustainable approach.

Remember, part of the definition of refactoring is that there’s no changes in functionality, which, from an end user’s perspective looks like the development team is doing absolutely nothing! Plus, it’s a myth to believe that you’ll ever be done refactoring – there’s always more to do.

A better approach is to be like a Boy Scout. See, the Boy Scouts have a rule: Always leave a campground cleaner than you found it.

Translating this to software: Every time you read some code, or certainly when you change a piece of code, make it just a little bit cleaner than it was before, while you’re at it. This will put you on a sustainable, constant trajectory towards the kind of code base that will make your mouth water!

Recommended Reading:

• Working Effectively with Legacy Code by Michael Feathers
• Refactoring by Martin Fowler